1. Field of the Invention
The present invention relates to graphical systems for creating and executing data flow programs, and more particularly to a method and apparatus which notifies a first function when a second function has produced a result so that the first function does not consume any CPU resources during this time.
2. Description of the Related Art
A computer system can be envisioned as having a number of levels of complexity. Referring now to FIG. 1, the lowest level of a computer system may be referred to as the digital logic level. The digital logic level comprises the computer's true hardware, primarily consisting of gates which are integrated together to form various integrated circuits. Other hardware devices include printed circuit boards, the power supply, memory, and the various input/output devices, among others. Gates are digital elements having one or more digital inputs, signals representing 0 or 1 states, and which compute an output based on these inputs according to a simple function. Common examples of gates are AND gates, OR gates, etc. It is also noted that there is yet another level below level 0 which can be referred to as the device level. This level deals with the individual transistors and semiconductor physics necessary to construct the gates comprising the digital logic level.
The next level, referred to as level 1, is referred to as the microprogramming level. The microprogramming level is essentially a hybrid between computer hardware and software. The microprogramming level is typically implemented by software instructions stored in ROM (read only memory), these instructions being referred to as microcode. The microprogramming level can be thought of as including various interpreters comprised of sequences of microcode which carry out instructions available at the machine language level, which is at level 2. For example, when an instruction such as an arithmetic or shift function appears at the machine language level, this instruction is carried out one step at a time by an interpreter at the microprogramming level. Because the architecture of the microprogramming level is defined by hardware, it is a very difficult level in which to program. Timing considerations are frequently very important in programming at this level and thus usually only very skilled, experienced microprogrammers operate at this level.
As mentioned above, the level above the microprogramming level is referred to as the machine language level. The machine language level comprises the 1's and 0's that a program uses to execute instructions and manipulate data. The next level above the machine language level is referred to as the assembly language level. This level includes the instruction set of the computer system, i.e. the various op codes, instruction formats, etc. that cause the computer to execute instructions. In assembly language each instruction produces exactly one machine language instruction. Thus, there is a one to one correspondence between assembly language instructions and machine language instructions. The primary difference is that assembly language uses very symbolic human-readable names and addresses instead of binary ones to allow easier programming. For example, where a machine language instruction might include the sequence "101101," the assembly language equivalent might be "ADD." Therefore, assembly language is typically the lowest level language used by programmers, and assembly language programming requires a skilled and experienced programmer.
The next level includes high level text-based programming languages which are typically used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers. The high level programming languages in this level, as well as the assembly language level, are referred to in this disclosure as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. For example, text-based programming environments have traditionally used a number of programs to accomplish a given task. Each program in turn often comprises one or more subroutines. Software systems typically coordinate activity between multiple programs, and each program typically coordinates activity between multiple subroutines. However, in a text-based environment, techniques for coordinating multiple programs generally differ from techniques for coordinating multiple subroutines. Furthermore, since programs ordinarily can stand alone while subroutines usually cannot in a text-based environment, techniques for linking programs to a software system generally differ from techniques for linking subroutines to a program. Complexities such as these often make it difficult for a user who is not a specialist in computer programming to efficiently program a computer system in a text-based environment.
The task of programming a computer system to model a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. For example, a computer programmer typically develops a conceptual model for a physical system which can be partitioned into functional blocks, each of which corresponds to actual systems or subsystems. Computer systems, however, ordinarily do not actually compute in accordance with such conceptualized functional blocks. Instead, they often utilize calls to various subroutines and the retrieval of data from different memory storage locations to implement a procedure which could be conceptualized by a user in terms of a functional block. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
One particular field in which computer systems are employed to model physical systems is the field of instrumentation. An instrument is a device which collects information from an environment and displays this information to a user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others. An instrumentation system ordinarily controls its constituent instruments from which it acquires data which it analyzes, stores and presents to a user of the system. Computer control of instrumentation has become increasingly desirable in view of the increasing complexity and variety of instruments available for use.
In the past, many instrumentation systems comprised individual instruments physically interconnected. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone. An incremental improvement in the manner in which a user interfaced with various instruments was made with the introduction of centralized control panels. In these improved systems, individual instruments were wired to a control panel, and the individual knobs, indicators or switches of each front panel were either preset or were selected to be presented on a common front panel.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems the user interacted with a software program executing on the computer system through the video monitor rather than through a manually operated front panel. These earlier improved instrumentation systems provided significant performance efficiencies over earlier systems for linking and controlling test instruments.
However, these improved instrumentation systems had significant drawbacks. For example, due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it was often necessary for a user to develop a program to control the new instrumentation system desired. As discussed above, computer programs used to control such improved instrumentation systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of instrumentation systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation data. Thus, development and maintenance of the software elements in these instrumentation systems often proved to be difficult.
U.S. Pat. No. 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a process, i.e. a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. Referring now to FIG. 1A, a graphically based programming environment can be represented at level 5 above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. As the user constructs the data flow diagram using the block diagram editor, machine language instructions are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a text-based computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems and modeling processes as well as for any type of general programming.
In programming a computer or modelling a process in a text-based environment, it is often necessary for a first sequence of code or routine to wait on a result that is produced by a second routine before the first can begin or continue operation. This is typically implemented by the computer system requiring the first routine to continually poll the second function, continually asking the second routine whether it is done. However, polling has a serious drawback in that precious CPU time is consumed.
In the system and method described in Kodosky et al, it was often necessary or desirable to have a first function waiting on a result from a second function before the first function could begin or proceed. For example, one part of a block diagram may be required to wait until another part finishes its task. This could be performed using global variables, with one function polling the value of the global variable until its value has changed, reflecting that the second function has produced the desired result. However, using global variables for this purpose requires considerable overhead, since the function that is polling is using CPU execution time. In addition, global variables may be undesirable in a data flow diagram. Therefore, a method and apparatus is desired which provides a more efficient mechanism for allowing a first function to be notified when a second function has produced a result.